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PURPOSE 


This note describes the PMX1 Frame Buffer management for 3D graphics applications for 
both PCI and AGP implementations. In addition, it also describes how applications written 
for SGLDirect 1 (which could always be guaranteed 3.5Mb texture space on PCX2, 
irrespective of graphics mode) will be managed. 


1. TECHNICAL BACKGROUND 
1.1. PMX1 Tile Accelerator (TA) Modes 


The tile accelerator modes provide optimum performance across a range of PMX1 interface 
and memory options. Copy Through will be the fastest mode on AGP systems but will carry 
the burden of requiring a significant buffer of video memory. If a buffer of required size in 
the video memory is unavailable then the Macro Tile mode will become the preferred mode 
of operation. 


1.1.1 Copy Through 


In Copy Through mode the TA reads a control stream consisting of ISP/TSP control words 
followed by object pointers for all objects that share those words. The TA reads the raw 
object data the pointers reference from Host memory and inserts the ISP and TSP control 
words and writes the resulting object data into frame buffer. 


1.1.2. Macro Tiling 


A macro tile is a tile that is composed of XxY micro tiles (PVR2 internal tiles i.e. 32x16). A 
render surface can be viewed as a single macro tile i.e. simple Copy Through mode or as a 
number of smaller macro tiles. The later would generally take the form of quarters or 
sixteenths in order minimise the cost of Host tiling. By breaking the scene data down into 
large sub units the number of times data is read from host memory can be kept to a minimum 
whilst minimising the amount of frame buffer required to store the parameters. 


De FB MEMORY ORGANISATION 


PMX1 supports a minimum memory configuration of 8Mb for both AGP & PCI. 


The PMX1 frame buffer is no different to any other graphics card and its use has to be split 
amongst competing applications. 
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The Frame buffer is segmented into 2 memory heaps, below 4Mb and above 4Mb. Each heap 
contains an ascending and descending heap as follows :- 


e Low 4Mb, ascending heap 

e Primary allocation area for 2D DirectDraw surfaces 

e Secondary allocation area for D3D/SGLDirect Textures & parameters 
e Low 4Mb, descending heap 

e Kernel Manager, 1 Core 
e Above 4Mb, ascending heap 

e Primary allocation area for D3D/SGLDirect textures 

e Only allocation space for SGLDirect I textures 

e Secondary allocation area for 2D DirectDraw/Primary surfaces 
e Above 4Mb, descending heap 

e 3D Parameters (D3D/SGLDirect | & I) 


2.1 AGP Memory Usage 


In addition to the Frame Buffer, AGP memory can be used to hold both 3D parameters and 
textures for both D3D & SGLDirect I. 


as 3D FRAME BUFFER MANAGEMENT 
3.1 Parameter Heap 
The most optimal performance solution is for the TA to run in copy through mode, whereby 


all the parameters for a complete scene are held in the frame buffer. In practice this is only 
viable if: - 


e There is > 8Mb memory 


e The scene size is small. 
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A more general solution is whereby the TA runs in macro-tile mode. Effectively, s/w will 
run using the largest macro tile size possible until it runs out of Frame Buffer parameter 
space. Under this condition, the following can happen: - 


e If AGP, parameters will overflow to run out of GART memory 


e Tile size can be reduced, reducing the amount of parameter space required. 


750K bytes of parameter buffer will be allocated in the Frame Buffer, 500K in the top 4MB 
heap, and 250K bytes in the lower 4Mb heap. This ensures that 3.5 Mb texture space 
(equivalent to PCX2) will be available on a PCI configuration. 


3.2 Texture Heap 


The texture heap will grow upwards until it reaches the Parameter heap. At this point, 
textures will be allocated out of the lower heap and then out of AGP. 


D3D titles already know that surfaces get lost on mode changes and that texture creation 
functions have to check for sufficient available memory. 


NOTE:- The big change for SGLDirect I titles is that there will have to be much tighter 
management of texture memory within modes. Titles will have to allocate textures after a 
mode change has take place and then release them before changing back. Failure to do so 
will cause Frame Buffer memory to be consumed and possibly prevent an original mode 
being restored. There is little the driver can do to protect memory against mode changes, 
therefore ISV education will be an important issue. 


The most problematic scenario for PMX is the support of SGLDirect | titles. These titles 
expect a fixed amount of Texture Memory (3.5 Mb), regardless of display mode. With 
SGLDirect I there was no ordering of the create/destroy texture calls with respect to display 
modes. For this reason, SGLDirect I titles will be restricted to using the top 4Mb of texture 
memory. The result of this is that the chances of titles failing, to load or have incorrect 
textures are very much reduced. However, problems could still arise if:- 


e The user launches an SGLDirect I title in a very high resolution (e.g. 
1600x1220x16) and attempts to allocate textures before it does its mode change to 
say 640x480. 


e User attempts to launch a SGLDirect I title with lots of current apps active. 
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By default, SGLDirect II allocates textures out of the Primary texture heap. For SGLDirect 
II applications it will be possible for texture memory to be allocated other than in the primary 
texture allocation heap as follows:- 


e AGP, setting the SGLTM_ AGP flag in the SGLTextureMap structure. 


e Secondary heap, by setting the SGLTM_Discardable flag in the SGLTextureMap 
structure. 


These are mutually exclusive options. 
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